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REMARKS 

Claims 1, 3-5, 7, 8, 13, 14, and 19-48 are presented for examination. 
Claims 2, 6, 9-12, and 15-18 were previously canceled in a prior Office Action 
Response. No claims are amended. 

The Advisory Action of January 24, 2005 (paper 1/05), item 5, explains 
that the "network including a destination device and an input device, wherein 
said destination device is external and separate from said input device" recited in 
the preamble, is not being given patentable weight because a "preamble is 
generally not accorded any patentable weight where it merely recites the 
purpose of a process or the intended use of a structure* and where the body of 
the claims does not depend on the preamble for completeness " . Applicants 
agree, but respectfully point out that the preamble of claim 1 does NOT merely 
recite the purpose of a process or intended use of a structure, and furthermore 
point out that the body of claim 1 DOES depend on the preamble for 
completeness. Specifically, the preamble of claim 1 recites, inter alia, "a 
destination device and an input device, wherein said destination device is 
external and separate from said input device". This is a structural recitation and 
not a mere statement of purpose or intended use, as is asserted by the Advisory 
Action. Furthermore, each and every paragraph in the body of claim 1 makes 
reference to one or both of "said destination device" or "said input device" for 
completeness. Thus, in accordance with the Examiner's statement of reasons for 
when it is proper to ignore a recitation in the preamble, it is clear that the 
present claim 1 does not fall under any of the recited criteria under which 
elements in the preamble may be ignored. Therefore, Applicants once again urge 
the Examiner to consider all claim elements and their recited interaction. 

In item 6, the Advisory Action once again asserts that Applicant's 
argument is that Unno does not teach "the file format (i.e. jpeg, bitmap, etc)", 
and that Unno teaches "converting file/data into a format that allowed to be 
transmitted in relation to the respective destination as shown in col. 6, lines 28- 
43, col. 10, lines 40-49, col. 14, lines 21-39". 
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Applicants repeat that our argument is NOT that Unno does not teach the 
use of file formats such as jpeg, bitmap, etc, and further request that our true 
argument, as explained in detail in previous Office Action responses, please be 
considered. Applicants have previously already conceded that Unno shows the 
use of different file formats, and shows the conversion between different file 
formats. However, Applicants do not claim to have invented the use of different 
file formats, nor the idea of converting a file from a first format to another. 
Rather, as is recited at least in claims 29 and 44, the present invention recites 
the conditional retrieval of a document based on a determination of the 
document's file format. Specifically, clams 29 and 44 state, 

"wherein prior to retrieving said image data, said client 
device submits a preferred file format to said image input 
device, and retrieves said image data only if said image data 
is in said preferred file format". 

By contrast, the cited Unno excerpts state, 

col. 6, lines 28-43 

"... An image rotation unit 2030 is used to rotate image data 
and an image compression/decompression unit 2040 performs 
compression/decompression on image data according to the 
JPEG standard from multi-level image data and according to 
the JBIG, MMR, or MH technique for two-level image data." 

Clearly, the above excerpt does not teach or suggest a conditional retrieval of a 
file based on its format. Continuing with. . . 

col. 10, lines 40-49, 

"In FIG. 12, reference numeral 1502 denotes an address book 
which is a database module for managing the destination of 
data. In accordance with the operation information given by 
the UI 1501, data is added, deleted, and/or acquired to/from 
the address book 1502 thereby giving information about the 
data destination specified by the user to various modules 
which will be described later. The address book stores data 
representing the data formats, the types of images allowed to 
be transmitted, and the resolutions, in relation to the 
respective destinations". 

The above excerpt explains that the address book maintains a listing of data 
formats a possible recipient machine expects (i.e. line printer, post script printer, 
fax machine, etc.), type of images allowed, resolution (such as 600 dpi laser 
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printer vs. 4800 dpi ink jet printer), and other characteristics supplied a software 
device driver. This excerpt, however, makes no mention of file formats (i.e. jpeg, 
etc.), nor does it make any reference to a receiver making conditional retrievals 
of a file based on its file format. The last excerpt cited in the Advisory Action 
states, 

col. 14, lines 21-39 

"In the case where a destination device is a server capable of 
communicating via the SLM, the address of the server and 
the designated folder in the server are detected from the 
address book 4051, and image data (two-level image data) 
obtained via a scanner is compressed according to the MMR 
technique and converted into the TIFF (Tagged Image File 
Format) form, as in the remote copy application. The 
resultant image data is stored in a particular folder of the 
server connected to the network (4500)". 

The above excerpt merely states that image data obtained by a scanner is 
compressed into a TIFF format, and stored in folder. As it is known in the art, 
the vast majority of scanners compress scanned files into a TIFF format. The 
only point of interest is that the above excerpt appears to provide a default 
storage folder for the scanned image. Irrespective, this excerpt again makes no 
mention of any conditional retrieving of a file based on its file format, as is 
required in the present invention. 

Lastly, the Advisory Action makes reference to rejections made in the 
Office Action mailed January 6, 2005 in regards to prior art U.S. Pat. 6,437,875 
to Unno, U.S. Pat. 5,689,642 to Harkins et al., and U.S. Pat. 6,219,151 to 
Manglapus et al. In the Office Action of January 6, 2005, Item 5 states that 
"Harkins ... teach [es] identifying an address of a remote storage device as shown 
in figures 1-3, col. 8, lines 29-54, col. 19, lines 62-col. 20 lines 54", and item 11 
states that "Manglapus teaches the printer sends an acknowledgement and 
SNMP traps to client indicating the location of stored print jobs (figures 4-5)". 
This rejection appears to be overlooking the data transfer sequence recited in the 
claims. That is, it appears to overlook the claim limitations of who sends an 
address, who retrieves a file, and the relationship of the provided address 
identifying a remote storage location. 
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Perhaps before noting the differences, it may be helpful to first briefly 
summarize the newly cited prior art, and the cited excerpts. Firstly in regards to 
Harkins, this reference is very similar to that of Unno. Harkins explains that 
there are many methods, i.e. modes, of sending information, such as printers, fax 
machines, email, video display, etc. (see Harkin Fig. 1), and different people 
prefer to receive information in different specific methods. Some people may 
prefer paper copies while others prefer electronic files, while still others may 
prefer screen/video messages. In the Harkins network, each user on the network 
can fill out a form specifying the method of how that user prefers to receive 
information (i.e. by email, to a specific black and white printer, to a specific color 
printer, to a specific fax machine, etc.). Thus, when a first user identifies a 
second user to whom information is to be sent (Fig. 2), the server automatically 
routes the information to the user's preferred method of receiving information 
(Figs. 4 and 5). Thus, in the Harkins reference, a user must first fill out a 
generic preference form and submit it to a server for future use. Whenever 
information is to be sent to a particular user, the server determines if a 
preference form is filled out for the particular user, and if it is, then it provides 
the preferred method for receiving information. 

Returning now to the cited excerpts, in regards to col. 8, lines 29-54, 
Applicants are at a loss to determine the relevance of most of this excerpt since 
most of it (lines 29-46) is merely a recitation of appendix, component parts, and 
modules in a network with no recitation of their interaction. As to lines 47-54, 
this section is a summary of Harkins 1 proposal for filling out a form listing a 
user ! s preferred method for receiving information, as explained above. 
Specifically, col. 8, lines 47-54 state, 

"Communication channel control begins with the receiver 
defining the preferred form(s) that documents should take 
when received. The user activates profile 150, shown in FIG. 
4, by selecting display user profile command (not shown) from 
the network administration menu 47. User profile 150 is 
completed by a user, for example Fred Smith, and published 
to network administration 105 using the publish command 
151 on the profile herald bar 152". 
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The filling out of this form is quite involved and its detailed explanation 
(Fig. 6) is described in col. 9, line 30 to col. 10 line 7. The above excerpt, 
however, is just half of the process. After a user fills out and sends the 
preference form to the server (i.e. publishes his/her preferences), any other user 
who wishes to send him/her information will be able to do so in his/her preferred 
form. The process for sending information to a receiver who has previously filled 
out a preference form is explained in col. 10, line 65 to col. 11, line 26. 

As to excerpt "col. 19, line 62 to col. 20 lines 54" cited in the Office Action 
of January 6, 2005, Applicants respectfully point out that the Harkins patent 
only has 14 columns of text, and thus Applicants cannot identify the intended 
excerpt. Please let us know if the excerpt citation was mistyped. 

In reference to the second cited reference, Manglapus explains (Fig. 2) that 
when a user 14 sends a print job to a print server (i.e. spooler 12) and the spooler 
12 forwards the print job to a printer 24, typically the spooler handles all 
communications with the user 14. However, it would be helpful for the printer 
24 to be able to send status updates (i.e. traps) of the submitted print job directly 
to the user 14 without having to use the spooler as the intermediary. In this 
case, the printer would traditionally have to obtain the user's address from the 
spooler 12, but this delays the transmission. In the process put forth by 
Manglapus, the user 14 inserts its own address into the print job file that it 
sends to the spooler 12. In this way, when the spooler forwards the print job to 
the printer 24, the printer can extract the user's address and transmit any status 
updates directly to the user 14 without having to request the address from the 
spooler 2. 

The Office Action asserts that "Manglapus teaches the printer sends an 
acknowledgement and SNMP traps to client indicating the location of stored 
print jobs (figures 4-5)." This is incorrect. The flow chart of Fig. 4 illustrates the 
insertion of the user's address into a print job file and the extraction/parsing of 
information from the print job file, as is explained in Col. 7, lines 24-37. 
Specifically, steps 100-120 are executed by the workstation, and steps 135-160 
are executed by the printer. Fig. 5 is a another recitation of the process for 
inserting the workstation's own address into the print job file, as is explained in 
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col. 9, lines 26-53. Thus, neither of these figures teach or suggest sending 
addresses to a client indicating the location of stored print jobs. The print jobs 
are executed at the printer (i.e. the printer prints the print jobs), and the client 
merely receives status updates regarding the execution of the print job. Thus, 
Applicants respectfully request that Examiner specify where Manglapus states 
that the printer sends to the client indications locating a stored print job, and 
further explain why a printer would ever send a print job to a client, who 
submitted the print job in the first place. 

In summary, the Harkins reference shows a server that maintains a list of 
delivery preferences for multiple users, and when information is to be sent to a 
specific user, the specific user's preferred printer, fax machine, email address, 
etc. is automatically identified to receive the information. In the Manglapus 
reference, the client that submits a print job identifies itself to the printer so that 
the printer can send it status updates (i.e. traps). Both of these reference are 
very different from the claimed invention. 

In the Harkins reference, there is no interaction between the recipient 
and the sender. Rather, the recipient submits a list of preferred delivery 
methods to a server, and the server is in charge of routing any transmitted 
information to the preferred delivery method. By contrast the present invention 
does not require, or utilize, a server. Rather in claim 1, the destination device 
submits directly to the input device an address identifying a remote storage 
location on the network. Upon receiving the address, the input device itself 
sends the input data to the identified remote storage device, and then proceeds to 
notify the destination device. By contrast in the Harkins reference, the client 
(i.e. input device) does not receive an address, nor does it send its input data 
directly to a specified remote storage location. Rather in the Harkins reference, 
after the client has selected a recipient, the server looks up the recipients 
preference form and automatically routs (i.e. creates a "channel" for) the 
information to the preferred receiving method. Furthermore, the present 
invention additionally requires that the destination device respond to the input 
device's notification that it has sent the input data to the remote storage 
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location, by then retrieving the input data directly from the remote storage 
location. 

In the Manglapus reference the client (i.e. input device) submits its own 
address along with a: print job to a printer server (i.e. spooler), which places the 
print job in queue for submission to a printer. When the print job is submitted to 
the printer (i.e. destination device), the printer extract the client's address and 
send it status updates regarding the execution of the submitted print job. Not 
only does Manglapus require the use of a network server, i.e. printer spooler, 
Manglapus makes no mention of a remote storage location, nor the use of an 
address for identifying the remote storage location, nor the retrieval of input 
data from the remote storage location. Thus, Applicants are at a loss to 
determine the relevance of the Manglapus reference in regards to the presently 
claimed invention. 

As to the Unno reference, it appears to be cited merely to show that it is 
known that an input device, a destination device, and a remote storage location 
may coexist on a network, but Unno does not teach nor suggest the specific data 
transfer sequence recited in the present claims. 

Thus, the present invention is not taught or suggested, singularly or in 
combination, by the cited prior art. 
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In view of the foregoing remarks, Applicants respectfully request favorable 
reconsideration of the present application. 



Please address all correspondence to: 



Epson Research and Development, Inc. 
Intellectual Property Department 
150 River Oaks Parkway, Suite 225 
San Jose, CA 95134 
Customer No. 20178 
Phone: (408)952-6000 
Facsimile: (408) 954-9058 
Customer No. 20178 

Date: February 22, 2005 



Respectfully Submitted, 




Rosalio Harch/ 
Registration No. 42,633 
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